Manage Order API
Best practices
This API meets the following Chorus business rules to ensure this API follows best practices.
| Chorus business rules | Method and endpoint | Description |
|---|---|---|
| Chorus-BIC101-1 | POST /orders/{orderId} | Pre-conditions to submitting a POST request Before submitting a POST request, you must: 1. Receive feasibility code 998 or 999 from an Order Feasibility request. 2. If your order requires a site visit, ensure the appointment(s) has been reserved. Post-condition for submitting a POST request After submitting a POST request, a response is received. Learn more about the Order Feasibility API Learn more about the Manage Appointment API |
| Chorus-ManageOrder-2 | POST /orders/{orderId} | Minimum mandatory order contacts provided on order submission The following order contacts must be provided on an order submission: 1. For product offers belonging to the Residential market segment, either with a site visit or requiring manual feasibility or MDU/ROW consent design and build, you must supply at least one Site contact type containing: - contactName - contactType - preferredPhone. 2. For product offers belonging to the Business or Education market segment, either with a site visit or requiring manual feasibility or MDU/ROW consent design and build, you must supply at least one Order, Site and IT contact type containing: - contactName - contactType - preferredPhone. |
| Chorus-ManageOrder-3 | POST /orders/{orderId} | Submitting order creation requests The product offers requested in order feasibility must be re-used in order creation for the order to remain feasible. Note: To change a product offer, you must submit a new feasibility request. |
| Chorus-ManageOrder-4 | POST /orders/{orderId} | Location of Equipment field For product offers that belong to the Business or Education market segments, a Location of Equipment value must be supplied. |
| Chorus-ManageOrder-5 | POST /orders/{orderId} | Order email notifications When notificationPreference is set to Notify, you must supply an email address value for the notificationEmail attribute. |
| Chorus-BIC101-6 | POST /orders/{orderId} | Connect Secondary Offer A location can only have a Secondary offer provisioned where there is an existing primary offer. The Primary service must have reached a state of Service Given. Note: There is no market segment restriction for Secondary Offers. A Secondary Offer can be provisioned against any active Primary Bitstream service. |
| Chorus-ManageOrder-7 | POST /orders/{orderId} | Connect and Replace order requests On receipt of a Connect and Replace order request, Chorus will send an INTENT_TO_DISCONNECT_ABANDONMENT notification to the Losing Service Provider (LSP). The LSP must respond within 5 days. The replacement order will proceed if the LSP: - approves the disconnect request - doesn’t respond to the Intent to Disconnect Abandonment notification within the required timeframe. The replacement will not proceed if the LSP rejects the disconnection request. Notes: - When in a scheduled state, the disconnect request may then be brought forward if needed. - Notifications that aren’t actioned are treated as accepted and scheduled. - The Connect request can’t be earlier than the Disconnect. Learn more about Connect and Replace orders |
| Chorus-ManageOrder-8 | PATCH /orders/{orderId} | Pre-conditions to submitting a PATCH request Before submitting a PATCH request, an order has been created and reached at least a state of Acknowledged/Accepted. Post-Conditions for submitting a PATCH request After submitting a PATCH request, a response is received. |
| Chorus-BIC105-9 | PATCH /orders/{orderId} | Validation of requests The amendOrderType attribute defines the type of Amend Order Request and determines how the request is validated for processing and content. |
| Chorus-BIC105-10 | PATCH /orders/{orderId} | Sending amend requests Chorus processes the following types of Amend Order Requests individually: - Interaction - Characteristic - orderDetails Note: You must wait for the response to each of these requests, before sending a subsequent request. We process the following types of Amend Order Requests irrespective of any other Amend Order Request being processed: - Escalate - Answer Notes: - We only process the attributes that belong to the specified type of Amend Order Request. Attributes related to other request types are not accepted. - If you require multiple types of Amend Order Requests (for example: characteristic and contact details), they must be sent as separate requests. |
| Chorus-BIC105-11 | PATCH /orders/{orderId} | Invalid order states for amend requests The following types of Amend Order Requests and order states do not allow changes: - Escalate - Feasibility (any substate), Closed (any substate) - Interaction - Closed (any substate) - Characteristic - Feasibility (any substate), Acknowledged/Received, In Progress/Intent to Cancel, Held/Intent to Cancel, Service Given (any substate), Completed (any substate), Closed (any substate) - Answer - Closed (any substate) - orderDetails - Acknowledged/Received, Feasibility (any substate), In Progress/Intent to Cancel, Held/Intent to Cancel, Service Given (any substate), Completed (any substate), Closed (any substate). Learn more about Chorus Portal statuses and sub-statuses |
| Chorus-BIC113-12 | GET /orders/{orderId} | Pre-conditions to submitting a GET order details request The following pre-conditions must be met: 1. Order feasibility has been completed. 2. Order ID has been generated. 3. The order can be in any state. Post-Conditions for submitting a GET order details request After submitting a GET request, a response containing the order information is received. |
| Chorus-BIC103-13 | DELETE /orders/{orderId} | Pre-conditions to submitting a DELETE order request The following pre-conditions must be met: 1. An order has been created. 2. The order is not in one of the following states: - Feasibility (any substate) - In Progress/Intent to Cancel - Held/Intent to Cancel - Held/Provider to Advise - Service Given (any substate) - Completed (any substate) - Closed (any substate). Post-Conditions for submitting a DELETE order request After submitting a DELETE order request: 1. You receive a response notifying that the state and substate of your order have changed to In Progress/Intent to Cancel. 2. Your cancellation request is processed, and you receive an Amend Order Notification advising that the order state and substate have changed to Closed/Cancelled. Note: The Delete function will only change the state of the order. |
| Chorus-BIC103-14 | DELETE /orders/{orderId} | Cancelling an order when an amend order request is pending When an order is cancelled, we will cancel any unprocessed Amend Order Requests. |